Seems to me here we drop the only usage of gojq, but we keep it still in bingo files (.bingo/gojq.mod, .bingo/Variables.mk, ...).
Should we drop it also from bingo?
Should be something like:

bingo-v0.9.0 get gojq@none

Good catch, if not used anywhere else, we should remove it from bingo files as well.

Done, and rebased, please re-review @pedjak

Unsupported ciphers are tracked in skippedCiphers and validated by TestNoSkippedCiphers — nice. But unsupported curves (where curveId() returns 0) are silently dropped here with no tracking or test.

If Mozilla adds a new curve that Go does not yet support, this would silently weaken the profile. Consider adding a skippedCurves slice with a corresponding test, mirroring the cipher handling:

id := curveId(c)
if id == 0 {
    skipped = append(skipped, "curve:"+c)
    continue
}

(Or a separate skippedCurves list if you prefer to keep them distinct.)

Yeah, I noticed that too... it may not even be a curve that isn't support, but simply not mapped in our own functions.

Good test — catches newly-added ciphers that Go does not support yet.

Consider also adding a basic smoke test that asserts the parsed profile values match expectations (e.g. modernTLSProfile.minTLSVersion == tls.VersionTLS13, intermediate has ≥9 ciphers). This would catch upstream JSON schema changes that parse without error but produce wrong data. The existing tests exercise the profiles indirectly, so this is a nice-to-have rather than a blocker.

minTLSVersion could change out from under us... i.e. intermediate could go to a newer version; so I'd prefer to avoid explicit value checks. Even the number of ciphers could drop as they are determined to be weak, so checking for a minimum number of ciphers is probably not what we want.
The missing cipher/curve option is a much more appropriate check.